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8 Where is It? Examining REXX WHEREIS 

By Eric Harper 

This article presents WHEREIS, an ISPF/REXX tool that allows users to quickly 
identify and review/change members within a TSO environment. 



18 OpenEdition MVS and the Bourne Shell - A User Experience: Part I 

By Evan Galen 

This article, the first in a three-part series, presents a fundamental comparison 
between the OpenEdition MVS shell and the SunOS Bourne shell, examines 
the environment used for the comparisons, and highlights what successfully 
tested on OpenEdition MVS. 

24 Managing CICS Resource Definitions 

By Richard Tsujimoto 

As the number of CICS systems increases at an installation, managing the CICS 
system definition data set (CSD) becomes more critical and time-consuming. 

30 MVS/ESA Problem Solving: IPCS VERBEXIT Commands 

By Tom Bryant 

This article highlights the little known details about IPCS VERBEXIT commands 
and how they can be used effectively for problem solving. 
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34 Protecting Your Network With and Without Firewalls: Part V — DNS Attacks 

By Mark Bell 

The DNS system, which resolves Internet names and addresses, is a target for 
hackers. While attacks using DNS can never be entirely prevented, a firewall 
will help to make things less convenient for the hacker. 


38 Security Issues for Common Work Tools: Part I — Fax and Email Systems 

By Leo A. Wrob el 

As a technologist, you know many of the nuts and bolts safeguards behind the 
maintenance and security of voice mail, fax, and other systems. As a non-legal 
person, however, it is important to know the security risks as well as the legal 
exposure presented by these systems. 
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By Jim Moore 
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S/2 INSIGHTS 


Building the Perfect Beast 

BY MICHAEL NORTON 


A s many of you probably already know. 
I’m the web master at the venerable 
OS/2 “Must-Have” Utilities, Links & 
List site (www.musthave.com), and spend 
an inordinate amount of time installing and 
experimenting with new products. And, as 
you might imagine, my system endures 
battery from the reconfiguration, installation, 
and uninstallation of software entails. Well, 
it endures most of the time. However, every 
six months or so I find myself snookered 
and have to restore from tape or reinstall 
OS/2. Usually I select the latter option, 
simply because some time during the life of 
the operating system I usually made a 
design decision which 1 regretted. A few 
years ago that might have been something 
such as not leaving room for the swap file, 
but along the way I’ve learned a thing or 
two, and machines I’ve installed bear my 
signature. I take a great deal of pride in my 
work, and I’ve come to look at the entire 
process as “building the perfect beast,” to 
borrow from a Don Henley album title. 


PATIENCE: THE FIRST PRINCIPLE 

We’re going to look at building the perfect 
beast in the next several columns while I 
rebuild my OS/2 system — which may very 
well take several months! The first principle 
in building an OS/2 system is p-a-t-i-e-n-c-e. 
Actually this is true not only of OS/2, but any 
computer system. The most common mistake 
in building systems is to install everything, 
immediately. I’ve even seen this madness at 
the hardware level, with network adapters, 
sound cards, internal modems, and other 
devices all being inserted simultaneously, 
while the user conveniently had the cover off 
the unit. The prudent approach to devices, 
of course, is to install one device, configure 
it, and test it, before moving to the next 
device, a procedure which at least gives you 
a prayer of resolving conflicts. However, 


while most technicians cringe at the idea of 
installing multiple physical devices simul¬ 
taneously, many do not hesitate when it 
comes time to load the software. 

Most of us know better, of course. We all 
know that sooner or later some rogue 
application will waste our meticulously 
tended system and cause us to scurry for the 
tape. Unfortunately, often times we’re hesi¬ 
tant to use the tape even at that point because 
the last “clean” backup we have does not 
include software installed after the offending 
program, meaning that software would have 
to be reinstalled and/or reconfigured! 

It is not always possible to avoid 
installing multiple software packages — that’s 
what test partitions are for. Typically, any 
installation will involve a certain number of 
clearly defined software packages — a word 
processor, browser, and dial-up networking, 
for example, might be the core packages for 
a domain. These are typically known in 
advance and can be tested beforehand to 
uncover any surprises or conflicts, then 
installed en masse on the user machines. This 
procedure, of course, is already followed in 
most large installations and is adhered to 
with almost religious fervor in an enterprise 
environment. Unfortunately, it is often 
neglected in smaller installations, and 
almost universally ignored in installations 
on a single machine. I suppose fewer users 
means more time to install, however. 


ACQUAINTING YOURSELF WITH THE SYSTEM 

In some ways we’re getting ahead of our¬ 
selves, however: We don’t even have the 
operating system installed, and we’re already 
talking about application software, albeit to 
accentuate the desirability of patience in such 
matters. Before installing OS/2 (or any other 
operating system, for that matter), it pays to 
acquaint yourself with the machine on which 
it will be installed. Gathering documentation 


on the machine is an excellent place to start. 
Comparing the hardware to the list of hard¬ 
ware compatible with OS/2 provided will 
reveal many potential problems that can be 
resolved in advance with a visit to the ven¬ 
dor’s home page or a call to technical sup¬ 
port. Strictly speaking, while many vendors 
do not support OS/2, I am usually able to 
locate someone in the organization who is 
the resident OS/2 guru and who often 
knows exactly how to make their product 
work under OS/2 or, in the worst case, can 
confirm that the product absolutely will not 
work under OS/2. In any case, it is better to 
know such things before the installation 
process is hopelessly stalled at 4 a.m. with 
users expecting sparkling new OS/2 systems 
waiting for them in four hours. 

Another marvelous resource for device 
drivers is the OS/2 Device Driver Repository 
(http://www.europe.ibm.com/getdoc/psmem 
ea/progserv/device/) maintained by IBM. 

STRIVING FOR PERFECTION 

So, now we have all of our documentation 
together. We’ve done our homework and 
know not only what hardware we’re going 
to be supporting, we’ve even got the latest 
device drivers. Time to bust OS/2 out of the 
box and load it up, right? Wrong, we’ve got 
a few more things to do, for we’re not out 
to just build a beast, but the perfect beast. 
Next month I’ll examine the rest of the 
pre-install routine. Remember, patience. EJ 

Was this column of value to you? If so , 
please circle Reader Response Card No. 42. 


Michael Norton is the workstation division manager 
at SofTouch Systems. Oklahoma City. Okla.. which 
provides both mainframe and PC software solutions. 
He has written mainframe manuals in addition 
to articles for a number of publications. Michael 
can be contacted at mnorton@softouch.com. 
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